說明

本篇文章將會介紹 CDN 路由，透過 CloudFront 的路由方法介紹如何讓客戶可以更快的使用服務。

DNS

我們先來回顧系列文章一開始的這張圖，圖裡面可以看到有一段 Domain Name Resolving，也就是把要存取的域名(ex: www.example.com )轉換成 IP 的過程。

圖片來源
This sketch note is under CC BY-NC-SA license.

可以看到在圖片中間，有一個 DNS 的區塊。那麼這邊的 DNS 運作細節，就跟你是使用哪一家 CDN業者有點關係。

比較

如果你有用過免費版的 CloudF"lare"，那麼一定對於其運作機制有個印象，如果要使用，會需要把對應的整個域名(ex: example.com) 交給 CloudFlare 「代管」。
後續你只需要針對自己的網站域名(ex: wwww.example.com) 「開啟」 CDN 功能即可。
因為 CloudFlare 直接可以控制對應的 DNS 紀錄，所以 CloudFlare 此時會讓你的域名成功解析。同時為了可以進一步做實驗，我們

#在台灣執行(HiNet)
$ dig www.cloudflare.com
;; ANSWER SECTION:
www.cloudflare.com.	65	IN	A	104.16.124.96
www.cloudflare.com.	65	IN	A	104.16.123.96

#在 us-east-1 執行
$ dig www.cloudflare.com
;; ANSWER SECTION:
www.cloudflare.com.	65	IN	A	104.16.124.96
www.cloudflare.com.	65	IN	A	104.16.123.96

那麼如果是 CloudFront，會如何呢?

#在台灣執行(HiNet)
$ dig s3.kgg23.com
s3.kgg23.com.		300	IN	CNAME	d2ofb91sesrtr4.cloudfront.net.
d2ofb91sesrtr4.cloudfront.net. 60 IN	A	13.35.166.45
d2ofb91sesrtr4.cloudfront.net. 60 IN	A	13.35.166.91
d2ofb91sesrtr4.cloudfront.net. 60 IN	A	13.35.166.92
d2ofb91sesrtr4.cloudfront.net. 60 IN	A	13.35.166.9

#在 us-east-1 執行
$ dig s3.kgg23.com
s3.kgg23.com.		300	IN	CNAME	d2ofb91sesrtr4.cloudfront.net.
d2ofb91sesrtr4.cloudfront.net. 60 IN	A	18.165.83.78
d2ofb91sesrtr4.cloudfront.net. 60 IN	A	18.165.83.92
d2ofb91sesrtr4.cloudfront.net. 60 IN	A	18.165.83.85
d2ofb91sesrtr4.cloudfront.net. 60 IN	A	18.165.83.76

咦? 為何 CloudFront 在不同區域解析了同樣的 CNAME，卻沒有解析出同樣的 IP?

是的，這就是希望跟以這做為例子進行說明。
想想我們在創建 CloudFront Distribution 時，是不是需要新增一筆 CNAME 紀錄?
以上面查詢的 s3.kgg23.com 為例子:

Name: s3.kgg23.com
Type: CNAME
Value: d2ofb91sesrtr4.cloudfront.net

搭配 CloudFront 的文件，可以看到這段文字

DNS 將請求路由到最適合請求的 CloudFront POP (節點)，通常是與延遲有關的最近 CloudFront POP，再將請求路由到該節點。

這代表，同一組 d2ofb91sesrtr4.cloudfront.net 可以在不同的地方(ex: 台灣 v.s. us-east-1)解析出不同的 IP。這樣就不同地區的客戶，針對不同的「目標」 IP 送出請求。
如果你進一步拿去查 IP 在哪，可以看到
比方說，從HiNet 的紀錄看，可以看到 TPE50(代表在 Taipei)；同 us-east-1 的紀錄看，可以看到 IAD (代表在 us-east-1)

$ dig -x 13.35.166.45 +short
server-13-35-166-45.tpe50.r.cloudfront.net.

$ dig -x 18.165.83.7 +short
server-18-165-83-76.iad55.r.cloudfront.net

如同講邊緣運算的文章中提到，軟硬體可以進步，但光速不變，能靠近用戶，就可以有較低的 Latency。

• 就像在台灣有機房的 GCP(有「區域」) 和 AWS(有 「LocalZone」)，在開 VM 時，就會明顯受益而有較低的Latency

那麼，我們是如何解析出 CNAME 對應的 IP 位置呢? 如果覺得好像派錯了，又該怎麼查呢?
這部分，我們留在明日的文章繼續討論。

• https://repost.aws/zh-Hant/knowledge-center/cloudfront-unexpected-edge-location